I think cliResult.dst is the final location, is that right? Should we download to a temporary location and then rename after verification instead? Advantages:

1. If the delete fails, this prevents the unsigned binary from being picked up as the cached binary on the next run.
2. If there was previously a signed (but outdated) binary, it will be left alone so the user can fall back to it if they want, if they are having trouble with downloading or verifying the new binary.

👍 I think it makes sense.

Same here

For air-gapped folks, I wonder if even attempting to reach out externally by default could be seen as a security risk. I think possibly this should be gated behind an option?

And maybe it should be defaulted to false, or maybe it is sufficient to communicate ahead of time about the option if we default it to true.

Or it could be a prompt, maybe. "Got 404 trying to download signature from $coder_url. Try downloading signature from releases.coder.com?" Something like that.

Although, will we always bundle the signature files with coderd? If so, this block will never execute right? (Except for an error downloading the signature from coderd, although maybe we should abort when there are errors.) Edit: I suppose it would be ran if coderd is an older version without the signatures.

will they also provide a public pgp key? will they continue to use detached gpg signatures? The code is now targeted for gpg signature verification.

Honestly not sure, maybe @jdomeracki-coder has an idea. If I understand correctly, the releases.coder.com fallback is only necessary for verifying older versions, and I am not sure if air-gapped teams will want to bother hosting their own service just to provide signatures for older binaries.

If that is true, then maybe all we need is an option that toggles whether to reach out externally for signatures, so it can be skipped in the air-gapped case.

Mostly though I am just worried that security teams will see the Coder extension reaching out to our servers and get spooked. But idk if this is a realistic worry, I am not a security expert 😅

We've had a lengthy discussion on this subject (shared the details on Slack)
Long story short: due to air-gapped customer requirements this option should be disabled by default.

Some folks have forked the CLI, should we provide a way they can add their own public keys to sign their own binaries or would we recommend they set the allowUnsignedBinaryWithoutPrompt setting for that case? (Also assumes there is a way to remove or replace the signature files in coderd, and it also has implications for the fallback to releases.coder.com).

We could make it configurable but those customers would have to sign the forked CLI binaries on their end as well.

Based on a discussion with @deansheather, it could look like this:

• Configurable optional setting eg. Binary signature public key path
• If above param would be specified, then the fallback to releases.coder.com wouldn't ever make sense (since the custom public key wouldn't fit the signatures)

This is definitely going to be a problem with customers using forked CLIs.

For the time being we could provide an option to execute the binary even if the signature verification were to fail.
This is obviously not ideal but would prevent blocking those customers from using the plugin.
Long-term we'll most likely implement the custom signature mechanism described above.

Thinking out loud: could we somehow make use of verifyDownloadLink here?

My thinking is, it uses an allow list, and it could be nice to allow the same list as we do for downloading the editors. This could even be used in place of allowUnsignedBinaryWithoutPrompt. verifyDownloadLink also resolves redirects so it shows the final URL (although maybe it should show both the original and final URLs).

Pressing "accept" could also add the URL to the allowlist for subsequent attempts (maybe it should be a third option like "Accept permanently" or something).

I could see reaching out to releases.coder.com if the signature was a 404, but should we be doing this if we got an error downloading the signature? Like a 502 or whatever? My thinking is that should be a hard failure (it would mean a problem with the deployment). Or a prompt asking whether to continue.

@deansheather provided feedback that we should avoid reaching releases.coder.com and ask the user with a pop-up if they want to run an unverified binary or reach out to release.coder.com to attempt to get a signature.

This will enable us to obtain explicit consent from the user to access an external site when they are on a restricted network.

Here's a potential flowchart, @jdomeracki-coder to review.

Also on mermaid.live

flowchart TD
    DownloadBin[Download binary from server]
    DownloadServerSig[Download signature from server]
    VerifySig[Verify retrieved signature]
    PromptUserCoderCom[Prompt user 'Could not retrieve binary signature from Coder server, it may be on an older version. Would you like to retrieve signature from coder.com, run the binary as-is, or exit?']
    DownloadCoderComSig[Download signature from releases.coder.com] 
    PromptUserRunAnyway[Prompt user 'Could not fetch any signatures, would you like to run the binary as-is or exit?']
    PromptUserInvalidSig[Prompt user 'Could not verify the authenticity of binary, it may have been tampered with. Would you like to run it anyway?']
    RunBinary[Run the binary]
    Exit

    DownloadBin --> DownloadServerSig
    DownloadServerSig -->|200| VerifySig
    DownloadServerSig -->|404 or error| PromptUserCoderCom
    PromptUserCoderCom -->|User selects 'Retrieve from coder.com'| DownloadCoderComSig
    PromptUserCoderCom -->|User selects 'Use as-is'| RunBinary
    PromptUserCoderCom -->|User selects 'Exit'| Exit
    DownloadCoderComSig -->|200| VerifySig
    DownloadCoderComSig -->|404 or error| PromptUserRunAnyway
    PromptUserRunAnyway -->|User selects 'Run anyway'| RunBinary
    PromptUserRunAnyway -->|User selects 'Exit'| Exit

    VerifySig -->|Invalid| PromptUserInvalidSig
    PromptUserInvalidSig -->|User selects 'Run anyway'| RunBinary
    PromptUserInvalidSig -->|User selects 'Exit'| Exit
    VerifySig -->|Valid| RunBinary

For most users, we will follow the green path with no prompt to the user.
sotce: here

---
config:
  layout: dagre
---
flowchart TD
    DownloadBin["Download binary from server"] --> DownloadServerSig["Download signature from server"]
    DownloadServerSig -- 200 --> VerifySig["Verify retrieved signature"]
    DownloadServerSig -- 404 or error --> PromptUserCoderCom@{ label: "Prompt user 'Could not retrieve binary signature from Coder server, it may be on an older version. Would you like to retrieve signature from coder.com, run the binary as-is, or exit?'" }
    PromptUserCoderCom -- "User selects 'Retrieve from coder.com'" --> DownloadCoderComSig["Download signature from releases.coder.com"]
    PromptUserCoderCom -- "User selects 'Use as-is'" --> RunBinary["Run the binary"]
    PromptUserCoderCom -- User selects 'Exit' --> Exit["Exit"]
    DownloadCoderComSig -- 200 --> VerifySig
    DownloadCoderComSig -- 404 or error --> PromptUserRunAnyway@{ label: "Prompt user 'Could not fetch any signatures, would you like to run the binary as-is or exit?'" }
    PromptUserRunAnyway -- User selects 'Run anyway' --> RunBinary
    PromptUserRunAnyway -- User selects 'Exit' --> Exit
    VerifySig -- Invalid --> PromptUserInvalidSig@{ label: "Prompt user 'Could not verify the authenticity of binary, it may have been tampered with. Would you like to run it anyway?'" }
    PromptUserInvalidSig -- User selects 'Run anyway' --> RunBinary
    PromptUserInvalidSig -- User selects 'Exit' --> Exit
    VerifySig -- Valid --> RunBinary
    PromptUserCoderCom@{ shape: rect}
    PromptUserRunAnyway@{ shape: rect}
    PromptUserInvalidSig@{ shape: rect}
    style DownloadBin fill:#00C853
    style DownloadServerSig fill:#00C853
    style VerifySig fill:#00C853
    style RunBinary fill:#00C853

This flow is getting complicated, need some time to think it through

Taking into consideration all constraints & requirements, I'm ok with the proposed flow.

Most of those prompts will only show up for a limited amount of time until customers upgrade their coder deployments (and could be bypassed using the optional settings)